Contribution à la vérication formelle et programmation par contraintes

ion des prédicats Le model checking symbolique utilise une représenta-tion efficace des formules booléennes. Une façon orthogonale pour accrôıtre l’effi-cacité est de simplifier le modèle en cours de vérification en prenant une abstraction.Ce principe a été utilisé en vérification de matériel (propriétés en logique temporellede programmes assembleur) [16] puis de logiciel [14]. Intuitivement, l’abstractionrevient à simplifier ou enlever des détails ou des composants entiers qui ne sont pasnécessaires à la propriété en cours de vérification. Le gain est évident puisque lapropriété à prouver est plus simple ; mais cela a aussi un coût puisque vérifier unmodèle plus abstrait peut éventuellement amener à de faux résultats.Dans le cas de la vérification des programmes, l’abstraction de prédicats per-met d’abstraire un programme en un programme booléen séquentiel, pour lequel leproblème d’atteignabilité est décidable. Cependant, si les prédicats réduisent l’es-pace de recherche et donc permettent de déterminer plus facilement la satisfaisabilitéde la formule sur le système abstrait, ils ont l’inconvénient de générer des “spuriouscounter-examples” que je nommerai “contre-exemples fallacieux”. En effet, l’intro-duction des prédicats induit une perte de sémantique et la formule abstraite peutêtre satisfaite alors que la formule concrète ne l’est pas. Le processus de vérificationpar model checking et abstraction de prédicats est donc le plus souvent mis en jeuen vérification de programmes sous la forme d’un processus itératif, nommé CE-GAR dans la littérature pour “Counter-Example Guided Abstraction Refinement”[17, 14, 15].Ce processus est en quatre étapes itérées (éventuellement une infinité de fois) : 1. Étape d’abstraction : choisir les prédicats et calculer la formule abstraite,2. Étape de vérification : tester la satisfaisabilité de la formule abstraite. Si elleest n’est pas satisfiable, alors la formule concrète ne l’est pas non plus. Sinon,soit τ un contre-exemple.3. Étape de simulation : vérifier que τ est effectif sur le modèle concret. Si oui,stopper avec détection de l’erreur τ . Sinon, τ est un contre-exemple fallacieux, I.2. LES MÉTHODES DE VÉRIFICATION FORMELLE11 4. Étape de raffinement : si τ est fallacieux, raffiner l’abstraction pour éliminerτ .Notons que l’étape d’abstraction nécessite d’une part de déterminer un ensemble deprédicats, mais nécessite aussi l’utilisation de procédures de décision pour trans-former le modèle concret en un modèle abstrait puisqu’il faut, pour chaque état,être capable de décider s’il satisfait ou non le prédicat.Ce processus de raffinement guidé par les contre-exemples est implémenté dansle model-checker NuSMV [17]. Pour la vérification de programmes, il est au cœurdu projet SLAM [4] et il est utilisé dans de nombreux autres outils (voir le tableaurécapitulatif dans l’état de l’art de D’Silva, Kroening et Weissenbacher [23]). Évidem-ment, la difficulté majeure de l’approche consiste à construire (de façon automatique)les prédicats les plus précis, qui génèrent le moins de contre-exemples fallacieux. Bounded model checking Toutes les techniques de model checking ci-dessus sontdes méthodes complètes : on fait l’hypothèse que l’ensemble des états est bornéet l’on peut donc énumérer tous les chemins dans ce graphe de transition d’états(via une représentation efficace des états et une abstraction). Avec l’émergence dessolveurs SAT fin des années 90, dont l’implémentation efficace permet de tester lasatisfaisabilité d’une formule booléenne contenant des milliers de variables, une autreapproche a été mise en application : le bounded model checking [7].L’idée est la suivante. Plutôt que d’explorer de façon dynamique l’espace desétats atteignables, il s’agit de construire une formule booléenne qui représente laconjonction de la négation de la formule à prouver et les chemins d’une longueurbornée k atteignables dans le graphe de transition d’états. De façon concrète, celasignifie que dans un programme, une boucle while sera dépliée c’est-à-dire rem-placée par la succession de if else correspondante : on itère k fois la substitutionde while(c)B; par if(c)B;while(c)B;. Dans le cas des circuits, c’est la relation detransition d’états qui est dépliée : si l’état E′ dépend de l’état E alors l’expressionde E′ est expansée en faisant apparâıtre les k états intermédiaires E0, E1, ...,Ek−1.Une fois la formule du programme ou du circuit “dépliée” jusqu’à la longueur k, laformule est passée au solveur SAT qui teste sa satisfaisabilité. Si elle est satisfiable,alors on a trouvé un cas d’erreur, sinon, on itère le processus avec une borne k plusgrande. Contrairement au model checking, le bounded model checking n’est pas uneméthode formelle complète. Cependant, c’est une des méthodes formelles les plusutilisées dans l’industrie, que ce soit pour la vérification de matériel que de logi-ciel puisqu’elle a le mérite d’être automatique et applicable à des exemples de tailleréelle. De plus, les contre-exemples fournis sont de longueur minimale dans le sensqu’ils sont trouvés par dépliages croissants. Ceci aide à la correction du système encours de vérification. I.2.3 Méthodes de vérification formelles utilisées dans mes travaux Dans mes travaux sur la vérification formelle des processeurs et des programmes,le cœur de la méthodologie de vérification est d’effectuer un model checking en calcu-lant les états par exécution symbolique [27]. Le graphe de transition d’états n’est pasconstruit de façon explicite, mais au contraire, les transitions d’états sont effectuées 12CHAPITRE